Design verification is essential to virtually any very large scale integration (VLSI) design project. One of the popular verification methods is logic simulation. Logic simulation software reports on how a circuit under design responds to a sequence of input vectors, so the designer can judge whether the circuit behaves as expected over an input sequence. The more vectors simulated, the greater confidence the designer has in the correctness of the designing circuit.
As circuit complexity increases and the time to market shortens, inadequate simulation speed becomes a major bottleneck in the design process. As a result, several special purpose machines have been built to simulate/emulate complex logic designs in hardware, rather than software. Such emulation/acceleration devices can provide several orders of magnitude of speed improvement during the simulation/emulation process. Thus, the necessity and usefulness of such devices has increased enormously with growth in the complexity of integrated circuits.
An emulation/acceleration engine operates to mimic the logical design of a set of one or more integrated circuit chips. The emulation of these chips in terms of their logical design is highly desirable for several reasons which are discussed in more detail below. It is, however, noted that the utilization of emulation/acceleration engines has also grown up with and around the corresponding utilization of design automation tools for the construction and design of integrated circuit chip devices. In particular, as part of the input for the design automation process, logic descriptions of the desired circuit chip functions are provided. The existence of such software tools for processing these descriptions in the design process is well mated to the utilization of emulation/acceleration engines which are electrically configured to duplicate the same logic function that is provided in a design automation tool.
Utilization of emulation/acceleration devices permits testing and verification, via actual electrical circuits, of logical designs before these designs are committed to a so-called “silicon foundry” for manufacture. The input to such foundries is the functional logic description required for the chip, and a set of photolithographic masks which are then used in the manufacture of the desired electrical circuit chip devices. The output of the foundry is a set of chips that are a physical manifestation of the logic description and masks provided to the foundry. However, it is noted that the construction of such masks and the initial production of circuit chips is expensive. Any passage of a given device having the prescribed logic functionality though such a foundry is an expensive and time consuming process which clearly should be undertaken only once. It is the purpose of emulation/acceleration engines to ensure such a single passage from the functional logic design stage through the stage of chip production via such a foundry.
Verifying that logic designs are correct before committing a design to manufacturing, therefore, eliminates the need for costly and time-consuming multiple passes through a silicon foundry. Debugging logic errors deep inside a logic chip can be extremely difficult because of very limited observability. Emulation provides two very significant advantages. Firstly, the proper verification of a functional logic design eliminates the need for a second costly passage through the foundry, and, secondly, and just as importantly, getting the design “right the first time” means that the design does not have to be debugged using foundry produced parts having design errors. Accordingly, production delays are significantly reduced and the time to market for the particular technology/technology improvements embedded in the integrated circuit chip is greatly reduced, thus positively impacting the ability to deliver the most sophisticated technological solutions to consumers in as short of time as possible.
An additional advantage that emulation/acceleration systems have is that they act as a functioning system of electrical circuits which makes possible the early validation of software which is meant to operate the system that the emulator/accelerator is mimicking. Thus, software can be designed, evaluated and tested well before the time when the system is embodied in actual circuit chips. Additionally, emulation/acceleration systems can also operate as simulator-accelerator devices thus providing a high speed simulation platform.
FIG. 1A illustrates a high-level block diagram of a typical emulation/acceleration system 10 (hereinafter referred to as emulation system 10), which is controlled by a host workstation 12. Emulation system 10 includes at least one emulation board 14, which, in turn, contains a plurality of emulation modules 16, as shown in FIG. 1B. Each emulation module 16 contains a plurality of emulation processors 18, as shown in FIG. 1C. Each emulation processor 18 is programmed to evaluate a particular logic function (for example, AND, OR, XOR, NOT, NOR, NAND, etc.). The programmed emulation processors 18, together as a connected unit, emulate an entire desired logic design under test 11 (i.e., the programmed emulation processors form part of a simulation “model” 15 for the logic design).
The overall simulation throughput of such a system is controlled (and limited) by the interface between the simulation logic model 15 running on the emulation system 10 and a runtime control program 20 running on a host workstation 12. Transactions between the runtime control program 20 and the simulation logic model 15 include reading and writing the values of logic facilities contained within the model and the execution of cycles to recalculate the model state. The default mechanism for these access transactions is through the emulator service interface which consists of a network connection 13 between the host workstation 12 and custom control cards 27 resident within the emulation system 10. The control cards 27 then interface with the emulation logic boards through a maintenance interface 31. The maintenance interface 31 has access to all logic and memory elements within the emulation board 14. Although the maintenance interface 31 has a relatively low latency, the latency of the network connection 13 is rather high (e.g., 1-2 milliseconds). Multiplied by several hundreds of thousands of operations, that 1-2 millisecond latency greatly impacts the overall simulation performance.
Further, if the emulator is cycling, the maintenance interface 31 has a further restriction in that accesses can only be performed within a narrow timing window, such that only a handful of accesses per cycle is possible. This significantly reduces the memory access bandwidth available via the maintenance interface 31.
An alternate communication path (i.e., a Direct Access Stimulus (DAS) card interface) may also be provided between the runtime control program 20 and the simulation logic model 15 that bypasses the network connection 13 and control subsystem. This path comprises a custom DAS card 33 plugged into a PCI slot 34 in the host workstation 12. A special high-speed multi-strand DAS cable 35 is connected between the DAS card 33 and the emulation board(s) 14 that contain the simulation logic model 15.
This DAS card interface is much more efficient than the network interface 13 because of the more direct connection to logic facilities. To use the DAS card interface most efficiently, a single “cycle forever” command is issued from the control program 20 to the emulation system 10 through the network interface 13. The emulation system 10 will then continuously evaluate the model state at the maximum raw cycle speed determined during the compilation of the model. This mode of operation is usually required when the emulator is physically connected to an external target system 36 that requires uninterrupted operation on the interface to the emulator. Read and write accesses from the control program 20 through the DAS card interface will then directly access the model facilities as they are being evaluated. These accesses will not incur the long latencies associated with the commands sent through the network interface 13.
Unlike the universal access to all model facilities permitted by the network interface and maintenance interface, the DAS Card interface is limited to accessing only primary inputs and primary outputs of the logic model 15. Internal model facilities that are not exposed cannot be accessed. Given enough routing resources within the emulator, any internal signal can be tapped onto and routed to the DAS card interface as if it were a logic model 15 primary output. Thus, the value for any internal signal can be directly read by the control program 20. However, it is not possible for the control program 20 to alter a value of the internal signal.
The emulator system architecture is designed such that internal signals within a logic model 15 can have only a single source. Synthesis programs which run at model compile time resolve cases with multiple sourced signals and modify the logic structure to insure that each signal has only one source. Thus an internal model signal already has a single source from a logic function within the model and thus cannot also be routed to an input from the DAS card interface.
There is a need for a mechanism to utilize the DAS card interface of an emulation system in an innovative fashion to enable the efficient alteration of internal model logic facilities while the emulator is actively cycling. Such a solution should overcome the emulator system architecture requirement that individual model signals can have only a single source and should enable the individual model signals to be directly accessible from the DAS card interface.